Subject: DLS Desirable Enhancements

From: [email-masked] (Paul Gacek)
Date: Thu, 29 Apr 93 07:27:30 PDT

Novell's list of desirable DLS enhancements as of April 29, 1993 is:

1. Flow Control 
2. PU 2.1 Support
3. Different media types/protocols
    a) Ethernet
    b) SDLC up stream
    c) channel
4. Capabilities exchange
5. Support over different transport (may be a moot point)
6. SDLC end to end (3b + existing functionality)
7. Class of service
8. Transmission Groups
9. Configuration
     a) Central Directory Server (CDS) like function - NetWare directory services/X500 naming
     b) SDLC resource  mac assignment scheme 	
10. Conformance & Interoperability program

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Fri, 30 Apr 1993 10:56:00 +0000

Having just joined this discussion, and not having participated in the
workshops (not through my own fault), I would appreciate some clarification
on some of the suggestions for enhancements to DLS.  Please forgive me if
I display my ignorance.

>Novell's list of desirable DLS enhancements as of April 29, 1993 is:
DLS is carried over TCP, which has flow control.  Further the individual
sessions within the connection all have flow control.  What exactly is
missing?

>2. PU 2.1 Support
DLS provides a data link connection which can be, and is, used for T2.1
traffic.  Are you asking for DLS to be supported on additional T2.1
platforms, such as the AS/400 and OS/2?  That would be product requirements,
not architectural enhancements.

>3. Different media types/protocols
SNA cannot be carried over "Ethernet" as the DIX specification does not
provide a reliable logical link control.  If by this requirement you mean
support of 802.2 LLC2 over 802.3 CSMA/CD LANs then that sounds like a good
requirement.

>    b) SDLC up stream
This seems reasonable.  It is somewhat strange that this is not provided
considering that being a secondary SDLC station is substantially simpler to
implement than being a primary SDLC station.

Since a router using DLS would presumeably deliver multiple logical link
connections to a single SDLC up stream (host) connection, it would seem to
me important that the up-stream connection support the group poll capability
already demonstrated on the 3174 token-ring gateway.  That would, in turn,
imply that the SDLC down-stream (terminal) support should be capable of
group polling an attached device.  That would require IBM releasing
additional documentation on how that protocol works.

>    c) channel
This could mean a couple of things:

A TCP/IP connection being delivered over a channel to DLS support in the
mainframe TCP/IP software (FAL/HAL).  That seems to me to be a product
requirement, rather than an architectural enhancement.

A DLS connection being terminated in a channel attached router which then
communicates with the mainframe appearing as one of: a 3172 terminating an
LLC2 LAN connection, a 3174 T2[.1], or a 3745 T4.

The remaining items look like good topics for discussion.

---

From: [email-masked]
Date: Fri, 30 Apr 93 08:28:25 PDT

Jim -

    Welcome to the DLSw SIG.

>sessions within the connection all have flow control.  What exactly is

    If you're thinking of ICMP source quench as a means of TCP/IP flow
    control ... dream on! (Just kidding ... it turns out no one has a
    serious implementation of ICMP source quench.)  All SNA
    internetworking vendors have been left to implement their own
    (read: proprietary) form of flow control for both sides of a switch
    element (i.e. flow controlling the SNA side when the TCP/IP network
    is congested and flow controlling the TCP/IP side with the SNA
    devices are congested).

    cisco has it's own, IBM has it's own (though, as has been pointed
    out, it's not documented), etc.  It essentially becomes a requirement
    when you locally terminate the DLC connection at the router.

>not architectural enhancements.

    I believe the issue here is SDLC NT 2.1 support or, more specifically,
    sensitivity to XID3 negotiation in the switch.  We haven't discussed
    putting DLS on a general purpose platform (yet).

>support of 802.2 LLC2 over 802.3 CSMA/CD LANs then that sounds like a good

    SNA over 802.3 is becoming more common now with OS/2 CommMgr,
    SNA Services/6000 and the AS/400 supporting it.  I don't have my
    OS/2 manuals with me at the moment but I thought SNA over "Etherand"
    (i.e. DIX and 802.3) was supported on OS/2 CommMgr.
    
    As far as DIX goes, this was a request from Netlink.  Shannon - any
    comments?

>implement than being a primary SDLC station.

    But the majority of the market has SDLC on the remote side making
    primary SDLC in DLS more important than secondary.  SDLC upstream
    has applicability for SDLC-to-SDLC (i.e. SDLC tunneling) as well
    as SDLC-on-the-host-side to LLC2-on-the-remote-side.

>additional documentation on how that protocol works.

    Good point ... sounds like a BNR feature request to me!  You are right
    on both accounts ... that group poll would be good for such a configuration
    and that it doesn't really work as documented.

>LLC2 LAN connection, a 3174 T2[.1], or a 3745 T4.

    I believe this was proposed by Novell.  Paul - any comments?

>The remaining items look like good topics for discussion.

-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Fri, 30 Apr 1993 15:35:00 +0000

In connection with flow control, my understanding of TCP/IP is certainly
much less than that of many other members of this group.  My practical
experience is limited to using the network from my workstation.  My
theoretical experience derives from reading, in more or less detail, about
150 of the RFCs plus another few dozen drafts.  That does, however,
include Van Jacobson's papers on flow control in TCP/IP.  However I have no
real personal experience in the area of flow control algorithms except when
I have been a victim of their failure.

I was not thinking of ICMP source quench, which even theoretically could not
be used for effective flow control.  I simply assumed, because of the
thousands of FTPs I have done over the past few years, that TCP/IP was
capable of adapting to the capacity of the network connection so as to
at least manage congestion, if not avoid it.  Isn't what TCP/IP does in
selecting a window flow control?